Web frontend の可觀測性 (observability)
sever application (Web server, batch server) と比べた Web frontend application の可觀測性 (o11y)の特徵 槪ね desktop application/smart phone application と同じ
畫面が有る
Request Rate (Requests per minute)
Errors (Errors per minute)
Availability
Duration/Latency (P50, P95, P99 secs)
Saturation (%)
application が開發者から離れた自由な場所で動作する
測定對象が手元に無い
user を模した動作を測定する
synthetic monitoring (外形監視)
例
Datadog の Synthetics
Google の PageSpeed Insights
MackerelMackerel.iconの外形監視
測定用の code を注意深く仕込んで一緒に配る
調査用 code を ad hoc に追加しづらい爲
user の手元で古い code が動き續けてゐるのは珍しい事ではない
問題が起きた時の log は調べやうと思った時にはもう消えてる爲
總ての動作に log を吐き蒐集する事は privacy 上の問題であり遣ってはいけない
real-user monitoring (RUM)
例
Datadog の RUM やブラウザログ蒐集
Google Analytics
Sentry
文書を表示すれば好いだけではなく、application の動作を測定する必要が生まれた
HTML+CSS+ちょっとした ECMAScript の Web 頁に於いて、頁下載迄の時閒や、畫像や CSS 等 assets の下載時閒、assets の讀み込みに依る layout shift が performance の主な氣に成りだった。後は access 數、page 遷移等 user 行動、SEO (Search Engine Optimization) / SMO (Social Media Optimization)、滞在時閒が等觀測するべき對象であった
これらは今でも觀測するべき對象である
但し頁や assets 全體の下載時閒はそんなに大切ではない
→LCP (Largest Contentful Paint)、critical assets
native application の樣に UX (User eXperience) の好い Web application を作りたい、と云ふ心意氣
さう云ふ競爭に成ってゐる
他の Web application や native application との競爭
可觀測性 (o11y)の三つの道具 (Tracing / Metrics / Logging) の觀點で蒐集する 測り方
in the lab
in the field
synthetic monitoring (外形監視)
user を模して Web site に access し測定する
PageSpeed Insights API (PSI)
各社
Google Cloud
Monitoring (舊 Stackdriver) にも synthetics が有る筈…
Datadog
Dynatrace
real-user monitoring (RUM)
Web application 自體に測定用 code を含めて deploy し、情報を集める
Google Analytics
Google Optimize
各社
Google Cloud
Firebase Performance Monitoring
Datadog
Dynatrace
error 蒐集
Google Cloud
Web browser 向けは無さそう
Sentry
Datadog
Web browser に用意されてゐる API
ECMAScript 起因で發生したエラーは ECMAScript でtry-catchなりwindow.addEventLisenter('error'), ...)で拾えるが、ECMAScript 起因でないエラーは拾えない
例: Content-Security-Policy 違反
fetch API によるものはfetch().catch()で拾えるけど、<img src="...">だと拾えないよね、とかそういう話題
メモリ使用量を測定する API にperformance.memoryといふものがあるけど、API 實行直前に GC が發生してゐたか、さうでないかによって測定結果が大きく變はって使ひ物にならない
GC 發生直後ならメモリ使用量が少なくなり、發生から充分時閒が經過している場合はゴミが殘っているので memory 使用量が大きくなってしまふはず
それを受け、この記事では performance.memory の代わりに事前に GC を實行してから memory 使用量を測定してくれる performance.measureMemory を使ひませう、という話が紹介されてゐる
自分逹で遣るには?
in the lab
各 Web browser で visual regressing test とかもやる
a11y test とかも一緒に走らせると好い
in the field
全部 Datadog で濟ませる手も有る
synthetics monitoring
AWS 模擬モニタリング好さそう
現代の E2E test
real-user monitoring
Google Analytics は入れる
A/B test も出來るって訣
Firebase Performance Monitoring 好さそう
error 蒐集は Sentry
新しい React では Web browser 組み込みの道具を使へと書いてある 各社
Dynatrace
Sentry
組織文化
A/B test によるビジネス改善
Google Analytics に Lighthouse のスコアを表示することで、ユーザ行動の分析にパフォーマンスを組み込む、という話